Revert "Add ExecutionPlan::apply_expressions() (#20337)" - #22437

#22437) (#22445)

- Backports #22437 from @alamb
to the branch-54 line

This PR cherry-picks the revert of `ExecutionPlan::apply_expressions()`
(#20337) onto `branch-54` so that DataFusion 54.0 does not ship the new
public API.

… trait method

The two MockReqExec impls in this test file override
ExecutionPlan::apply_expressions, added when apache#20337 introduced the
trait method. Upstream apache#22437 reverted that addition, so the
overrides now reference a trait method that no longer exists and the
test crate fails to compile after rebasing onto main. Removing both
override blocks restores the trait-default behavior (no-op) used
before apache#20337.

…20337)" (apache#22437) (apache#22445)

- Backports apache#22437 from @alamb
to the branch-54 line

This PR cherry-picks the revert of `ExecutionPlan::apply_expressions()`
(apache#20337) onto `branch-54` so that DataFusion 54.0 does not ship the new
public API.

…20337)" (apache#22437) (apache#22445)

- Backports apache#22437 from @alamb
to the branch-54 line

This PR cherry-picks the revert of `ExecutionPlan::apply_expressions()`
(apache#20337) onto `branch-54` so that DataFusion 54.0 does not ship the new
public API.

…ache#22437)

…he#22437) (apache#24018)

## Which issue does this PR close?

<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases.
You can link an issue to this PR using the GitHub syntax. For example
`Closes #123` indicates that this PR will close issue #123.
-->

- Informs: apache#23814
- Informs:
datafusion-contrib/datafusion-distributed#584

This change does not close the above issues because it does not
implement a way to tell if a node is a producer dynamic filters.

## Rationale for this change

See apache#23814 and
datafusion-contrib/datafusion-distributed#553.

To send dynamic filter updates across the network, there needs to be a
way to get access to `PhysicalExpr` from `ExecutionPlan`. As discussed
in apache#23814, the cleanest way
to do this is to add `ExecutionPlan::apply_expressions`, which mirrors a
similar method for logical plan nodes.

## What changes are included in this PR?

There's 3 commits in this PR:

Firstly, commit 1 re-applies the changes in
apache#20337 (reverted in
apache#22437).

Some of the reasons for why the original PR was reverted include
(a) `apply_expressions` is too complicated to implement and there's no
concrete need to justify this complexity
(b) there was no usage of `apply_expressions` inside this repo

To address (a)
- justification for adding this method is provided in
apache#23814
- commit 2 in this PR adds helper methods `apply_expression_roots` and
`apply_no_expressions` which abstract away the `TreeNodeRecursion`
complexity from implementors. Now, `apply_expressions` very trivial to
implement ex.
```rust
fn apply_expressions(
    &self,
    f: &mut dyn FnMut(&Arc<dyn PhysicalExpr>) -> Result<TreeNodeRecursion>,
) -> Result<TreeNodeRecursion> {
    apply_expression_roots([&self.predicate_1], f)
    apply_expression_roots([&self.predicate_2], f)
    apply_expression_roots([&self.other_expression], f)
}
```
- the method traverses over `&Arc<dyn PhysicalExpr>` rather than `&dyn
PhysicalExpr` to reduce complexity around lifetimes

To address (b):
- commit 3 adds a usage of `apply_expressions` in
`physical-plan/src/aggregates/mod.rs`. Previously, there was a hack that
checked if a filter was pushed down using `Arc::strong_count(dyn_filter)
> 1`. Now it uses `apply_expressions`
- similarly, commit 4 removes `is_used` from dynamic filters which used
to check Arc references counts to see if a filter was pushed down. Now,
the hash join uses `apply_expressions` to find pushed down filters.

## Are these changes tested?

Yes.

## Are there any user-facing changes?

There's a new mandatory method `ExecutionPlan::apply_expressions()`. See
the upgrading guide and documentation for details.

---------

Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>